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THE  JOB  TASK  ANALYSIS/SKILLS  AND  KNOWLEDGE  MARRIAGE  (PART  1) 


T.  M.  Ansbro  and  W.  A.  Hayes 

CNET/TAEG  NEPDIS  Development  Team,  CNET  HQ.  NAS  Pensacola 


As  job/ task  analysis  methodology  continues  to  advance  In  sophistication, 
the  computer  takes  over  an  ever  greater  share  of  the  work  of  analysis,  leaving 
less  and  less  of  formerly  judgemental  areas  to  assumption.  But,  assumption 
still  functions  where  job  Mskllls  and  knowledges"  are  assigned  as  underlying  or 
component  to  tasks  In  Inventories.  f 

i 

So  far.  In  front-end  analysis  of  the  workplace,  task  Interrelationships, 
rankings  by  complexity,  and  degrees  of  commonality  can  be  readily  determined  by 
the  computer.  If  task  00165  In  package  017  proves  common  to  16  others  In  an 
Inventory  of  2500,  has  a complexity  Index  of  1.25,  and  embodies  all  the  subor- 
dinate work  behaviors  of  137  other  tasks,  the  computer  can  record  these  fea- 
tures and  position  the  subject  task  appropriately  In  an  output  hierarchy.  It 
can  also  sort  on  the  basis  of  Identifying  or  descriptive  data  Included  In  the 
task  record  In  the  Inventory.  Such  processing  gets  pretty  far  down  Into  speci- 
fics of  work  behaviors  underlying  tasks,  but  It  doesn't  affix  identified  mani- 
pulative or  processing  skills  and  static-descriptive  or  process-associated 
knowledge  (information)  elements  to  those  tasks. 

This  paper  (Part  I)  describes  a matrix  of  "skills  and  knowledge"  elements 
to  augment  a model  front-end  job/task  analysis  subsystem  (NEPDIS — Naval  Enlis- 
ted Professional  Development  Information  System)  and  discusses  such  alterna- 
tives as  adding  these  data  to  the  master  job/task  Inventory  or  providing  an 
ancillary  skills  and  knowledge ""inventory  for  use  of  the  training  program 
developer.  ^ 


As  ’’front-end"  job/task  analysis  methodologies  have  progressed  and 
continued  to  advance  In  sophistication,  the  computer  takes  over  an  even  greater 
share  of  the  work  of  analysis,  leaving  less  and  less  of  formerly  judgemental 
areas  to  panel-of-experts  analysis,  evaluation,  and  cataloguing.  Identifi- 
cation and  description  of  tasks  in  inventories  appear  fairly  concrete,  as  they 
do  for  such  task  component  work  behaviors  as  task  elements  (Johnson  and 
Rlchmann,  1975).  What  analysis  Is  possible  so  far  with  the  task  (and  its 
accompanying  descriptive  factors)  as  the  sole  data  source  has  yielded  task  com- 
plexity Indexes,  hierarchies  expressive  of  task  Interrelationships,  and  task 
commonality  Indicators  within  and  among  occupational  fields.  With  such  outputs 
of  job/ task  analysis  producible  by  computer  programming,  assumption  and 
subject-matter  expert  (SME)  consensus  might  well  be  expected  to  fade  Into  the 
background.  However,  assumption  still  functions  where  such  work  behaviors  as 
job  "skills  and  knowledges"  are  or  must  be  assigned  as  underlying  or  component 
to  tasks  In  Inventories. 

In  Navy  manpower  management,  ship  and  squadron  manning  documents  and  job 
(billet)  descriptions  are  dependent  in  the  main  upon  extensive,  detailed,  and 
comprehensive  inventories  of  operational,  maintenance,  administrative,  military 
watchstanding,  and  other  tasks  (as  well  as  ship,  systems,  and  equipment  data). 
Personnel  distribution,  rating  ass‘jnment,  advancement,  and  training  (espe- 
cially training)  depend  upon  inventories  of  skills  as  well  as  tasks;  and  the 
training  community  needs  to  take  the  job/task  Inventory  "audit  trail"  down 
farther  still — to  the  level  where  "job  knowledge"  can  be  associated  directly 
with  "job  skills"  to  support  job  tasks. 

This  paper  (Part  I)  describes  an  attempt  to  produce  a matrix  of  "job  skills 
and  knowledges"  elements  to  augment  model  front-end  job/task  analysis  subsystem 
currently  under  development  by  the  staff  of  the  Chief  of  Naval  Education  and 
Training  (CNET)  and  Training  An* lysis  and  Evaluation  Group  (TEAG)  elements  in 
Pensacola,  Florida.  The  subsystem  model  is  the  Training  Analysis  Subsystem  of 
the  Naval  Enlisted  Professional  Development  Information  System  (NEPDIS)  (Davis, 
1976,  1977,  1977a,  1977b). 

The  NEPDIS  model  currently  stores  some  23,000  Naval  Avionics  rating  tasks 
in  its  inventory.  Occupational  data  acquisition  was  accomplished  for  other 
ratings  in  the  Naval  aviation  community,  ten  In  all,  but  these  data  are  not  yet 
In  the  computer.  As  a result,  occupational  data  stored  and  analyzed  to  date  by 
NEPDIS  remain  In  the  major  functional  category  of  Maintenance.  A typical 
listing  of  an  avionics  maintenance  task  is  shown  In  Figure  1. 

With  computerized  analysis  of  such  data  as  typified  by  this  entry  In  the 
Aviation  Electrician's  Mate  (AE)  job/task  inventory  under  NEPDIS,  tasks  may  be 
ranked  by  complexity;  and  degrees  of  commonality  (from  the  identical  to  an 
agreed-upon  level  of  similarity)  (Davis  and  Perry,  1980)  may  be  established. 
Task  Interrelationships  may  also  be  established.  Some  tasks  obviously  contain 
many  component  work  behaviors  that  are  also  contained  In  other  tasks  of  lesser 
complexity  and  scope;  some  tasks  duplicate  the  work  behaviors  of  others,  some- 
times regardless  of  the  task  titles  involved.  Tasks  shown  to  "embody"  other 
(subordinate  or  component)  tasks  are  termed  "Omnibus"  tasks;  the  tasks  shown  to 
be  component  to  the  Omnibus  tasks  are  termed  "Embodied"  tasks  (Figure  2).  In 
the  NEPDIS  job/task  Inventory  (JTI)  AE  task  00165  in  package  017  may  be  shown 
to  have  a complexity  Index  of  1.25,  prove  common  to  28  others  In  a one-rating 
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Inventory  of  3700  tasks,  and  embody  all  the  component  work  behaviors  of  137 
other  tasks.  The  computer  can  record  these  features  after  producing  them  via 
analysis,  and  It  can  position  the  subject  task  appropriately  in  any  specified 
output  hierarchy.  It  cais  also  sort  on  the  basis  of  identifying  or  descriptive 
data  included  in  the  task  record  in  the  inventory  (Ansbro,  1978).  Such 
processing  gets  pretty  far  down  into  the  specifics  of  work  behaviors  underlying 
tasks,  but  it  doesn't  extend  beyond  identifying  job-related  skills.  Figure  3 
shows  task  "signature  block"  (work-behavior  descriptive  data)  printed  out.  The 
five  skill  areas  included  in  the  task  signature  block  contain  statements  of 
work  behavior  that  would  appear  to  be  as  descriptive  of  elements  (or 
components)  of  a task  as  of  the  skills  that  they  represent.  They  are 
definitive,  small  in  compass,  and  specific  to  (and  therefore  underly)  task 
performance;  therefore  attached  to  other  descriptive  data  for  the  task. 

Herein  lies  a problem  for  the  training  program  developer  or  curriculum 
designer.  To  design  a training  course,  he  needs  an  inventory  of  tasks  to 
describe  course  graduate  job  performance  capabilities  and  to  provide  realistic 
practical  exercises  and  performance  tests.  Successful  student /graduate  task 
performance  when  matched  with  on- job  (billet)  requirements  in  the  fleet  (also 
tasks)  serves  as  a reasonable  predictor  of  successful  performance  on  the  job. 

However,  can  a course  cover  all  the  tasks  that  the  graduate  must  perform  on 
the  job  in  his  fleet  assignment?  The  best  that  we  can  hope  for  is  coverage  of 
these  tasks  that  best  represent  fleet  requirements.  The  analysis  that  results 
from  this  realization  requires  intricate  grouping  and  cataloguing  of  work 
behaviors.  Selection  of  representative  tasks  really  involves  selection  of 
those  underlying  behaviors  component  to  or  most  widely  transferable  among  tasks 
assumed  to  be  representative  of  fleet  job  requirements. 

The  transferable  component/supporting  work  behaviors  underlying  task 
performance  are  skills.  Skills,  stated  in  behavioral  action  language,  resemble 
tasks.  Indeed,  the  workplace  and  the  schoolhouse  both  use  task  and  skill  ter- 
minology almost  interchangeably.  As  an  example,  welding  is  described  as  a 
transferable  skill,  since  welding  something  to  something  else  is  component  to 
performing  many  metal  fabrication  and  repair  tasks.  However,  depending  upon 
how  a work-behavior  statement  reads  ("weld  fire-hose  support  bracket  to  bulk- 
head"), welding  may  be  regarded  as  the  action  part  of  a task  statement. 

Welding  as  a major  work  behavior  can  also  be  regarded  as  more  encompassing  than 
a task;  it  can  represent  an  entire  worker  career,  or  the  sole  mission  or  output 
of  a shop  or  department.  Soldering,  somewhat  similar  technically,  but  a consi- 
derably smaller  skill,  is  usually  termed  just  that—a  skill.  Viewed  from  a 
task-descriptive  orientation,  it  is  also  a task  element.  But,  because  of  its 
simplicity,  subordinate/ component  nature,  and  wide  applicability  (therefore 
transferability)  to  task  performance,  it  is  generally  considered  to  be  a skill, 
and  in  the  occupational  fleld(s)  of  electricity/electronics,  a basic  one,  at 
that. 


On  the  premise  that  if  the  schoolhouse  is  to  train  the  graduate  to  perform 
on  the  job  in  the  fleet,  the  instructional  program/course  designer  must  attempt 
to  replicate  the  best  representative  and  most  critical  tasks  from  that  target 
environment;  then,  he  must  ferret  out,  verify  a.ad  train  on  those  skills  found 
to  be  component  to  those  tasks  selected  for  training  and  transferable  to  those 
known  to  exist  in  the  workplace  but  not  selected  for  training  Therefore,  the 
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training  community  needs  extensive  and  comprehensive  JTIs  with  task-descriptive 
data  as  fully  fleshed  out  as  possible;  and  it  is  certainly  more  than  merely 
convenient  to  have  skills  appropriately  identified  as  such.  Further,  in  any 
career  continuum,  it  must  follow  that  in  the  earlier  training  programs  (basic, 
apprentice,  initial  job-entry),  the  concentration  of  training  effort  is  on 
skills,  transferable  to  the  job  environment  where  they  may  be  applied  and 
refined  in  a work-and-OJT  setting.  Advanced  specialized  training  still  teaches 
skills,  but  task  performance  figures  somewhat  more  prominently,  as  higher  level 
technician  training  more  closely  approximates  the  real-world  environment  of  the 
graduate's  ultimate  work  site. 

As  mentioned  earlier,  skill  statements  resemble  task  (and  task  elemr^t) 
statements:  There  are  action  verbs,  objects  of  action,  and  job-environment 

conditions  and  work-performance  standards.  It  is  necessary  to  make  one  clear 
distinction  if  there  is  to  be  any  observable  difference  between  these  state- 
ments (in  an  Inventory).  In  the  task  statement,  the  object  of  the  action  is 
specific:  a clearly  identified  or  coded  item  (system  or  subsystem  component, 

equipment  item,  part,  form,  machine,  Instrument,  etc.)  In  the  skill  statement, 
the  object  of  the  action  is  not  a specific  item;  it  can  be  typical  of  a group 
or  class,  a "generic"  item  (mild  steel  plate,  galvanized  sheet  metal  ducting, 
bar  stock,  tubing,  circuit  wiring,  solid  state  printed  circuits,  etc.),  even  a 
synthesized  or  composite  item  generated  for  such  a purpose  as  training  or  prac- 
tice of  an  identified  skill  action.  As  tasks  fall  into  hierarchies,  so  also  do 
skills.  A "troubleshooting"  task  (in  NEPDIS:  "Isolate  Fault/Troubleshoot 

object")  employs  subordinate  (component)  "troubleshooting"  skills: 

selecting/using  references,  selecting/uslng  tools,  selectlng/uslng  support 
materials,  selectlng/uslng  support  equipment,  and  selectlng/uslng  test  equip- 
ment. 


The  principal  mechanistic  reason  for  making  these  task/skill  distinctions 
in  the  NEPDIS  Training  Analysis  subsystem  is  the  need  for  the  computer  to 
recognize  the  distinctions  in  its  progress  through  analysis  toward  such  outputs 
as  billet-specific  task  inventories  and  rating-specific  skill  inventories. 
NEPDIS  front-end  analysis  was  designed  to  be  totally  computer-served  and  to 
conduct  all  job/task/ skill  analysis  for  designated  users  at  the  "front-end"; 
hence,  the  emphasis  on  coding,  detailed  identification  and  descriptive  factors, 
and  other  aspects  of  an  audit  trail  from  task  identification  through  reference 
source. 

Job  knowledge,  or  the  task/skill  performance  enabling  base  (information/ 
data);  lies  at  the  bottom  of  the  audit  trail.  Information  from  all  reference 
sources  pertinent  to  task/skill  performance  can  be  assumed  to  fit  into  a rela- 
tively simple  matrix,  an  example  of  which  is  shown  in  Figure  4.  A NEPDIS- 
conducted  literature  search  based  on  reference  text  support  of  occupational 
data  already  in  the  JTI  indicated  substantial  reference  support  for  the  details 
of  task  and  task  element  performance.  However,  little  test  support  for  those 
behaviors  identified  as  component  skills  was  found  in  these  references.  For 
instance,  what  to  solder  and  at  what  point  to  solder,  and  what  tools  and 
materials  applied  to  the  task  element  were  amply  covered  by  reference.  How  to 
solder  was  not.  Hence,  in  a Navy-designed  front-end  job/ task  analysis  sub- 
system built  to  support  Instructional  Systems  Development  (ISD),  the  subsystem 
developers  discovered  that  in  some  instances  they  had  provided  themselves  with 
relatively  light  direct  reference  text  support  for  developing  the  essentials  of 
some  skills  training.  By  tracking  back  through  the  appropriate  job 
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task-oriented  references  and  by  recourse  to  rating- specific  texts  and  existing 
skills-tralning  school  texts,  the  necessary  reference  support  can  be  found. 

But  it  is  not  direct,  and  it  is  not  totally  and  specifically  contained  within 
the  master  JTI  for  the  rating  or  occupational  field. 

NEPDIS  front-end  analysis  k A been  designed  with  the  avowed  intent 
of  keeping  all  the  job/task  (and  skill)  analysis  at  the  front  end. 

An  instructional  systems  developer  was  to  receive  all  the  various 
inventories  (subsystem  outputs)  needed  to  develop  curricula/instruc- 
tional programs,  etc.  without  having  to  Mgo  back  to  the  front  end” 
himself  to  analyze  or  further  analyze  data;  especially,  he  should  not 
have  to  collect  raw  data. 

One  simple  solution  is  to  add  such  text  references  in  the  appropriate  spot 
in  the  task  identification  block  in  the  master  JTI.  Another  is  to  provide  a 
brief  structured  addendum  to  the  master  JTI,  this  item  strictly  for  the  use  of 
training  program  development  personnel.  Figure  5 illustrates  the  general  r ope 
of  basic  supporting  Information  useful  to  the  developer  of  skills  training.  In 
essence,  this  example  would  suggest  the  beginning  of  an  adjunct  task/ skills 
performance-supporting  Information  Inventory  or  skills  and  knowledge  library. 

A third  alternative  is  to  construct  a matrix  such  as  the  one  shown  (in 
concept)  in  Figure  A,  and  code  it  to  the  task  signature  block  in  the  JTI.  The 
matrix  generally  illustrates  the  task  support  hierarchy:  from  the  top  down, 

task  performance  is  supported  by  any  number  of  task  elements;  the  task  elements 
are  supported  by  (and  Incorporate)  manipulative  and/or  information-processing 
skills;  and  these  skills  are  supported  by  static  descriptive  and  process- 
associated  knowledge  items  (the  enabling  Information  base).  For  practical 
incorporation  into  the  JTI,  identified  skills  can  be  cross-coded  to  task  iden- 
tification codes,  and  bodies  of  Information  identified  as  skill-supporting 
items. 

The  alternatives  mentioned  above  represent  current  NEPDIS  effort  to  marry 
the  already  definitive  job  task  information  in  the  JTIa  with  equally  definitive 
supporting  skill  and  knowledge  data.  The  intent  also  is  to  maintain  a visible 
and  easily  followed  audit  trail  throughout  the  Training  Analysis  Subsystem. 
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AVIATION  ELECTRICIAN’S  MATE  JOB/TASK 
INVENTORY 
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FIGURE  2.  0*1 1 BUS/EMBODIED  TASK  RELATIONSHIP 

(AVIATION  ELECTRICIAN'S  HATE  INVENTORY) 
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FIGURE  3.  SAMPLE  SKILL-AREA  CITATIONS  PRINTED  OUT  IN  NARRATIVE 
(AVIATION  ELECTRICIAN’S  MATE  JOB/TASK  INVENTORY 


FIGURE  4.  RELATIONSHIP  OF  INFORMATION  BASE  TO 
TASK/SKILL  PERFORMANCE 
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FIGURE  5.  SKILL-SUPPORTING  INFORMATION  PACKAGE 
FOR  THE  TRAINING  PROGRAM  DEVELOPER 
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